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Attract 

Distributed  systems  are  multi-processor  Information  processing  systems  which  do  not  rely  on 
the  central  shared  memory  for  communication.  This  paper  presents  ideas  and  techniques  in 
modelling  distributed  systems  and  its  application  to  Artificial  Intelligence.  In  section  2 and 
3,  we  discuss  a model  of  distributed  systems  and  its  specification  and  verification 
techniques.  We  introduce  a simple  example  of  air  line  reservation  systems  in  Section  4 and 
illustrate  our  specification  and  verification  techniques  for  this  example  in  the  subsequent 
sections.  Then  we  discuss  our  f urther  work. 
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Massachusetts  Institute  of  Technology.  Support  for  the  laboratory’s  artificial  intelligence 
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of  Defence  under  Office  of  Naval  Research  contract  N0Q0I4-75-C0522 


I.  This  paper  will  appear  in  the  proceeding  of  the  5-th  International  Joint  Conference  on 
Artificial  Intelligence,  Cambridge,  U.S.A.,  August,  1977. 
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1.  Introduction 

Distributed  systems  are  multiprocessor  information  processing  systems  which  do 
not  rely  on  the  central  shared  memory  for  communication.  The  importance  of  distributed 
systems  has  been  growing  with  the  advent  of  "computer  networks"  of  a wide  spectrum: 
Networks  of  geographically  distributed  computers  at  one  end,  and  tightly  coupled  systems 
built  with  a large  number  of  inexpensive  physical  processors  at  the  other  end.  Both  kinds 
of  distributed  systems  are  made  available  by  the  rapid  progress  in  the  technology  of  large 
scale  integrated  circuits.  Yet  little  has  been  done  in  the  research  on  semantics  and 
programming  methodologies  for  distributed  information  processing  systems. 

Our  main  research  goal  is  to  understand  and  describe  the  behavior  of  such 
distributed  systems  in  seeking  the  maximum  benefit  of  employing  multi-processor 
computation  schemata. 

The  contribution  of  such  research  to  Artificial  Intelligence  is  manifold.  We 
advocate  an  approach  to  modelling  intelligence  in  terms  of  cooperation  and  communication 
between  knowledge-based  problem  solving  experts.  In  this  approach,  we  present  a coherent 
methodology  for  the  distribution  of  active  knowledge  as  a knowledge  representation  theory. 
Also  this  methodology  provides  flexible  control  structures  which  we  believe  are  well  suited 
for  organizing  distributed  active  knowledge.  Furthermore  we  hope  to  make  technical 
contributions  to  the  central  issues  of  problem  solving  such  as  parallel  versus  serial 
processing,  centralization  versus  decentralization  of  control  and  information  storage,  and 
the  "declarative-procedural"  controversy. 

This  paper  presents  ideas  and  techniques  in  modelling  distributed  systems  and  its 
application  to  Artificial  Intelligence.  In  section  2 and  3,  we  discuss  a model  of  distributed 
systems  and  Its  specification  and  verification  techniques.  We  introduce  a simple  example  of 
air  line  reservation  systems  in  Section  4 and  illustrate  our  specification  and  verification 
techniques  for  this  example  in  the  subsequent  sections.  Then  we  discuss  our  further  work. 
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2.  A Model  of  Distributed  Systems 

The  actor  model  of  computation[Greif&Hewitt75,  Greif75,  Hewitt&Baker77]  has 
been  developed  as  a model  of  communicating  parallel  processes.  The  fundamental  objects 
in  the  model  of  computation  are  actors.  An  actor  is  a potentially  active  piece  of 
knowledge  (procedure)  which  is  activated  when  it  is  sent  a message  which  is  also  an  actor. 
Actors  interact  by  sending  messages  to  other  actors.  More  than  one  transmission  of 
messages  may  take  place  concurrently.  Each  actor  decides  how  to  respond  to  messages  sent 
to  it.  An  actor  is  defined  by  its  two  parts,  a script  and  a set  of  acquaintances.  Its  script 
is  a description  of  how  it  should  behave  when  it  is  sent  a message.  Its  acquaintances  are  a 
finite  set  of  actors  that  it  directly  knows  about.  If  an  actor  A knows  about  another  actor 
B,  A can  send  a message  to  B directly.  The  concept  of  an  event  is  fundamental  in  the 
actor  model  of  computation.  An  event  is  an  arrival  of  a message  actor  M at  a target  actor 
T and  is  denoted  by  the  expression  (T  <»  M).  A computation  is  expressed  as  a partially 
ordered  Set  of  events.  We  call  this  partial  order  the  "precedes"  ordering.  Events  which 
are  unordered  in  the  computation  can  be  concurrent.  Thus  the  partial  order  of  events 
naturally  generalizes  the  notion  of  serial  computation  (which  is  a sequence  of  events)  to  that 
of  parallel  computation. 

A collection  of  actors  which  communicate  and  cooperate  with  each  other  in  a goal 
oriented  fashion  can  be  implemented  as  a single  actor.  In  essence  actors  are  procedural 
objects  which  may  or  may  not  have  local  storage.  Some  may  behave  like  procedures  and 
some  may  behave  like  data  structures.  Modules  in  distributed  systems  are  modelled  by 
actors  and  systems  of  actors.  In  this  regard,  IC  chips  can  be  viewed  as  actors. 

Knowledge  and  intelligence  can  be  embedded  as  actors  in  a modular  and 
distributed  fashion.  For  example,  /rumes[Minsky75,  Kuipers75], 

uni ts[Bobrow&Winograd76],  Aet/i0j[Lenat75],  stereotj/pes[Hewitt75]  e.t.c.  which 
represent  modular  knowledge  with  procedural  attachments  are  modelled  and 
Implemented  as  actors.  In  the  context  of  electronic  mail  systems  and  business  information 
systems,  objects  such  as  forms,  documents,  customers,  mail  collecting  stations,  and  mail 
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d istributi n g stations  are  easily  modelled  and  implemented  as  actors. 

Messages  which  are  sent  to  target  actors  usually  contain  continuation  actors  to 
indicate  where  the  result  of  the  receipt  of  the  message  should  be  sent.  By  virtue  of 
continuations  in  messages,  the  message-passing  in  the  actor  model  of  computation  realizes  a 
universal  and  yet  flexible  control  structure  without  using  implicit  mechanisms  such  as  push 
down  stacks.  Various  forms  of  control  structures  such  as  go-to’s,  procedure  calls,  and 
coroutines  can  be  viewed  as  particular  patterns  of  message  passing  [Hewitt76]. 

This  model  of  computation  has  been  implemented  as  a programming  language 
PLASM A[Hewitt76l  The  script  of  an  actor  can  be  written  as  a PLASMA  program.  We 
believe  that  PLASMA  will  provide  a basis  for  programming  languages  for  distributed 
systems.  In  section  5,  an  example  of  PLASMA  programs  is  given  as  a script  of  a 
flight-data  actor  in  the  model  of  a simple  air  line  reservation  system. 

3.  Techniques  for  Specification  and  Verification 

In  designing  and  implementing  a distributed  (message-passing)  system,  it  is 
desirable  to  have  a precise  specification  of  the  intended  behavior  of  the  distributed  system. 
Also  we  need  sound  techniques  for  demonstrating  that  implementations  of  the  system  meet 
its  specification.  Below  we  give  some  of  the  central  ideas  of  our  specification  and 
verification  techniques  based  on  the  model  introduced  in  the  previous  section.  The  more> 
detailed  work  will  be  found  in  [Yonezawa77]. 

In  specifying  the  behavior  of  a distributed  system,  it  is  not  only  practically 
infeasible,  but  also  irrelevant  to  use  global  states  of  the  entire  system  or  the  global  time  axis 
which  governs  the  uniform  time  reference  throughout  the  system.  We  are  concerned  with 
states  of  modular  components  of  a distributed  system  which  interact  with  each  other  by 
sending  messages.  Thus  we  are  interested  in  the  states  of  actors  participating  in  an  event  at 
the  instance  at  which  the  message  is  received. 

In  our  specification  language,  conceptual  representations  are  used  to  express 
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local  states  of  actors  (modules).  Conceptual  representations  were  originally  developed  to 
specify  the  behavior  of  actors  which  behave  like  data  structures[Yonezawa&Hewitt76]  We 
have  found  them  very  useful  to  express  states  of  modules  in  distributed  systems  at  varying 
levels  of  abstraction  and  also  from  various  view  points.  The  basic  motivation  of 
conceptual  representations  is  to  aid  in  providing  a specification  language  which  serves  as  a 
good  interface  between  programmers  and  the  computer  and  also  between  users  and 
implementors.  Conceptual  representations  are  intuitive  clear  and  easy  to  understand,  yet 
their  rigorous  interpretations  are  provided.  Instead  of  going  into  details  of  syntactic 
constructs  of  conceptual  representations,  we  give  examples.  Below  !<»xp>  is  the  unpack 
operation  on  <«xp>  which  means  writing  out  all  elements  denoted  by  <«xp>  individually. 

(CELL  A)  ;a  cell  containing  A at  in  commit. 

( QUEUE  ABC)  ;a  queue  with  clcmentt  ABC. 

{NODE  {car:  A ){cdr:  B))  ;o  LISP  node  containing  A and  B. 

{CUSTOMER  (fellers:  i!m})(#-o/-jiompj-neede<f:  n)) 

;a  customer  visiting  a post  office 
;who  carrie * lettert  *m  and  wantt  n tlampt. 

{POST-OFFICE  {cuitomer:  { fcj)  {collector:  { fei})) 

;a  pott  office  which  containi  cuttomert  !c  and  mail  collector t !cl. 

It  should  be  noted  that  a conceptual  representation  does  not  represent  the  identity  of  an 

actor.  It  only  provides  a description  of  the  state  of  an  actor.  Thus  to  state  that  an  actor  Q 

is  in  the  state  expressed  by  a conceptual  representation  {QUEUE  A B C),  an  assertion  of  the 

following  form: 

(Q  it-a  {QUEUE  A B C)) 

is  used.  Some  examples  of  specification  using  conceptual  representation  are  given  in  the 
later  sections. 

Symbolic  evaluation  is  a process  which  interprets  a module  on  abstract  data  to 
demonstrate  that  the  module  satisfies  its  specification.  Symbolic  evaluation  differs  from 
ordinary  evaluation  in  that  I)  the  only  properties  of  input  that  can  be  used  are  the  ones 
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specified  in  the  pre-requisites,  and  2)  if  the  symbolic  evaluation  of  a module  M encounters 
an  invocation  of  some  module  N,  the  specification  of  N is  used  to  continue  the  symbolic 
evaluation.  The  implementation  of  N is  not  used.  The  technique  of  symbolic  evaluation 
has  been  studied  by  a number  of  reseachers,  for  example  [Boyer&Moore75, 
Burstall&Darlington75,  Hewjtt&Smith75,  Yonezawa75,  King76]. 

Our  method  for  symbolic  evaluation  of  distributed  systems  is  an  extention  of  the 
one  developed  for  symbolic  evaluation  of  programs  written  in  SIMULA-like 
languages[Yonezawa&Hewitt76].  One  of  the  main  techinques  we  employ  in  symbolic 
evaluation  is  the  introduction  of  a notion  of  situati ons [M cCa rt h y& H a y es69],  A situation 
is  the  loco l state  of  an  actor  system  at  a give  moment.  The  precise  definition  of  locality  in 
the  actor  model  of  computation  is  found  in  [Hewitt&Baker77].  By  relativlzing  states  of 
modules  with  situational  tags  which  denote  situations,  relations  and  assertions  about 
states  of  modules  in  different  situations  can  be  expressed.  Explicit  uses  of  situational  tags 
seem  to  be  very  powerful  in  symbolic  evaluation  of  distributed  systems.  A simple  example 
Is  given  in  Section  7. 

Another  technique  we  employ  in  symbolic  evaluation  is  the  use  of  actor 
induction  to  prove  properties  holding  in  a computation.  Actor  induction  is  a 
computational  induction  based  on  the  precedes  ordering  (cf.  Section  2)  among  events.  It 
can  be  stated  intuitively  as  follows: 

"For  each  event  E in  a computation  C,  if  preconditions  for  E imply 
preconditions  for  each  event  E’  which  is  immediately  caused  by  E,  then 
the  computation  C is  carried  out  according  to  the  overall  specifications.” 


The  precedes  ordering  has  two  kinds  of  suborderings,  1)  the  activation  ordering, 
which  is  the  causal  relation  among  events,  and  2)  the  arrival  ordering,  " arrivet-before ", 
which  expresses  ordering  among  events  which  have  the  same  target  actor.  Thus  there  are 
two  kinds  of  actor  induction  according  to  these  suborderings.  An  example  of  the  induction 
based  on  the  arrival  ordering  is  used  in  Section  7. 


4.  Modelling  an  Air  Line  Reservation  System 

— A specification  of  an  Air  Line  Reservation  System  -- 

As  an  illustrative  example  of  distributed  systems,  let  us  consider  a very  simple  air 
line  reservation  system.  Suppose  we  have  just  one  flight  which  has  a non-negative 
number  of  seats.  A number  of  travel  agencies  (parallel  processes)  independently  try  to 
reserve  or  cancel  seats  for  this  flight,  possibly  concurrently.  We  model  an  air  line 
reservation  system  as  a flight  actor  F which  behaves  as  follows  The  flight  actor  F accepts 
two  kinds  of  message,  ( reierve-a-teat :)  and  (caneel-a-teat:).  When  F receives 
(reterve-a-teai:),  if  the  number  of  free  seats  is  zero,  a message  (no- more- mat »:)  is.  returned. 
Otherwise  a message  ( ok-itt-reterved :)  is  returned  and  the  number  of  free  seats  is  decreased 
by  one.  When  F receives  (caneel-a-teat:),  if  the  number  of  free  seats  is  less  than  the 
maximum  number  of  seats  of  the  flight,  a message  (ok-itt-cancelled:)  is  returned  and  the 
number  of  free  seats  is  increased  by  one,  otherwise  ( ioo-many-cancol *:)  is  returned. 
Furthermore  requests  by  (rcscrve-a-tcat:)  and  (canccl-a-xcat:)  are  served  on  a 
first-come-first-served  base. 

To  write  a formal  specification  of  the  air  line  reservation  system,  we  need  to  describe  the 
states  of  the  flight  actor.  For  this  purpose,  we  use  the  following  conceptual  representation 

( FLIGHT  (teat  t- free:  <m>)  (tize:  <s») 

which  describes  the  state  of  a flight  actor.  The  number  of  free  seats  is  <m>  and  <s>  is  the 
size  of  the  flight  in  terms  of  the  total  number  of  seats.  The  formal  specification  of  the  air 
line  reservation  system  using  this  conceptual  representation  is  depicted  in  Figure  I below. 
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<«i»n I:  (ereate-flight  <=  S) 

(pre-cond:  (S  > 0)  > 

(return:  F*  > 

(poit-cond:  (F  it-n  ( FLIGHT  (teat  t- free:  S)  (rite:  S)))» 

(event:  (F  <=  (reterve-a-teat:)) 

(ease- 1: 

<pre-cond:  (F  ii-a  {FLIGHT  (teau-free:  0)  (lire;  $)))> 

(next-cond:  (F  it-a  ( FLICIIT  (teau-free:  0)  (size:  S))» 

(return:  ( no-moro-teati ;)  >) 

{cate- 2: 

(pre-cond: 

(F  it-a  ( FLIGHT  {tcati-free:  N)  {tit c:  S))) 

(N  > 0)  > 

(next-cond:  (F  it-a  {FLIGHT  {teau-free:  N - 1)  (tite:  S)))> 

(return:  {ok-itt-retcrved:)  >)> 

(event:  (F  <=  {cancel-a-tea I:)) 

{cate-1: 

(pre-cond:  (F  it-a  {FLIGHT  { tcatt-free : S)  (lice:  S)))> 

(next-cond:  (F  it-a  {FLIGHT  {teau-free:  S)  {tixe:  S)))> 

(return:  ( loo-many-cancclt :)  » 

{ case-2 : 

(pre-cond: 

(F  it-a  ( FLIGHT  {teau-free:  N)  {tize:  $))) 

(N  < S)  > 

(next-cond:  (F  is-a  ( FLIGHT  {teau-free:  N ♦ 1)  {size:  S)))> 

Crefurn:  {ok-itt-cancclled:)  > ) > 

(for-eventt:  E,  E' 

« chore  E = (F  <=  M),  E’  = (F  <=  M’J 
(pre-cond: 

(F  it-a  {FLIGHT  (tcatt-free:  ...)  (lice:...))) 

(E  arrive t-be fore  E')> 

(cauted-evonls:  reply- for[E],  reply-for[E’]> 

<pott-cond:  (reply-for[E]  preccdet  reply-for[ E’])  » 

Figure  1 A Specification  of  the  Air  Lina  Reservation  System 
(A  Specification  for  the  Flight  Actor) 

The  first  <eveni:...>-dause  states  that  a new  flight  actor  F is  created  by  an  event 
where  the  create-flight  actor  receives  a positive  number  S.  <actor>*  means  that  <actor>  is 
newly  created.  The  second  <cuont:...>-clause  has  two  cases  according  to  the  number  of  free 
seats  at  the  moment  when  the  flight  actor  F receives  (rcterve-a-tcat:).  When  the  number  of 
free  seats  is  zero  (Cate-I),  the  state  of  F does  not  change.  When  It  is  positive  (Caie-2),  the 
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number  of  free  seats  decreases  by  one  as  stated  by  the  assertion  in  the  <nc*i-eond:...>-clause. 
The  notation  in  Figure  1: 


(event:  (T  <=  M) 

<pre-eond:  ...  > 

<next-cond: ...  <»ss«rtion>  ...  > 

< return : <*ctor>  > > 

means  that  when  an  event  (T  <«  M)  takes  place,  if  the  preconditions  are  satisfied,  <a$sertion>s 
in  the  <M>xt-con<f:...>-clause  hold  immediately  after  the  event  until  the  next  message  arrives 
at  T.  <actor>  in  the  <reiurn:...>-clause  is  returned  as  the  result  of  the  event.  <next-cond:...> 
differs  from  <pott-cond:...>  in  that  assertions  in  <p©u-coiuf:...>-clause  hold  at  the  time  <actor> 
is  returned,  whereas  assertions  in  <nexi-conrf:...>-clause  hold  at  the  time  the  next  message 
arrives.  The  next  message  may  arrive  at  T before  or  after  a reply  for  the  previous  message 
is  returned.  The  third  <cvcnt:..>clause  is  for  the  cancelling  event,  which  is  interpreted  in  a 
similar  way.  The  <for-eventt:  ...>-clause  states  that  requests  (messages)  received  by  the  flight 
actor  are  served  on  the  first-come-first-served  base.  Namely,  the  replying  events  for  events 
E and  E’  take  place  in  the  same  order  as  E and  E*. 

5.  Implementing  the  Air  Line  Reservation  System 

Our  strategy  to  implement  the  air  line  reservation  system  (specified  in  the  previous 
section)  is  as  follows.  First,  we  implement  a flight-data  actor  which  satisfies  the 
specification  in  Figure  I on  the  condition  that  it  is  always  activated  serial  l y.  Then  we 
put  some  protecting  (or  scheduling)  mechanism  on  the  flight-data  actor  so  that  the  protected 
flight-data  actor  may  satisfy  the  specification  of  the  air  line  reservation  system. 

In  Figure  2 below  we  give  an  implementation  of  the  flight-data  actor  in  PLASMA. 
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;create-fiight-data  reccivet  a tize  s of  flight. 

;a  variable  size  it  tot  to  a. 

;a  variable  seats-free  it  tat  to  «. 
;the  following  cases -elaute  it 
{returned  at  an  actor  which  bchavat  at  a flight-data. 

; when  a (re.terve-.Jl  mettage  it  received, 

i if  seats-free  it  zero, 
;(no-...)  mettage  it  returned. 

; other  wite 

i seats-free  it  decreated  by  one. 
;(ok-...)  mettage  it  returned. 

; when  a (cancel-.*)  mettage  it  received, 

;if  seats-free  it  equal  to  size, 
;(too-.*)  it  returned, 
iotherwite 

;seats-free  is  increased  by  one. 

;(ok-~.)  it  returned. 

Figure 

It  is  fairly  straightforward  to  write  a specification  for  this  flight-data  FD  by  using  a 
conceptual  representation: 

(FUGUT-D/ITA  ( tealt-free : <m>)  (size:  <s>))  ' 

which  describes  the  state  of  a t light-data  actor.  The  number  of  free  seats  is  <m>  and  <s>  is 
the  size  of  the  flight  in  terms  of  the  number  of  seats.  Note  that  If  FD  were  sent  more  than 
one  message  concurrently,  anomalous  results  would  be  caused.  For  example,  in  the 
implementation  in  Figure  2,  if  ( reterve-a-teat :)  and  (cancel-a-teat:)  messages  are  sent 
concurrently,  ( no-more-teatt :)  message  might  be  returned  even  if  there  are  vacant  seats. 
Therefore  in  order  to  model  the  air  line  reservation  system  by  using  the  above 
implementation  of  a flight-data  actor,  the  way  it  is  used  must  be  restricted  so  that 
interference  between  different  activations  does  not  take  place.  As  suggested  in  the 
beginning  of  this  section,  the  restriction  we  Impose  is  that  FD  must  be  used  serially  In  the 
sense  that  FD  is  not  allowed  to  receive  a message  until  the  activation  by  the  previous 
message  is  completed.  Now  the  flight-data  actor  can  be  used  to  implement  the  air  line 


(create-flight-data  =t)  = 

(tel  (size  initially  c) 

(seats-free  initially  t ) 
then 

(cases 

(=>  (reterve-a-teat:) 

(rules  seats-free 
(=>  0 

( no-more-teatt :)) 

(=>  elte 

(seats-free  ->  (seats-free  - 1)) 
( ok-ilt-reterved :)))) 

(=>  (cancel-a-teat:) 

(rules  seats-free 
(=>  size 

(too-many-cancelt:)) 

(=>  elte 

(seats-free  ->  (seats-free  * 1)) 
(ok-itt-cancelled:))))  )) 


-II- 


l 


♦ 


reservation  system  under  this  restriction.  We  give  a formal  specification  for  the 
flight-data  actor  in  Figure  3 below. 


(event:  (create-f  light-data  <=  S) 

<pre-cond:  (S  > 0)> 

< return : FD*  > 

< pott-cond : (FD  ii-a  {FLIGHT-DATA  {teati-free:  S)  (lire:  S)))» 

(event:  (FD  <=  ( rcierve-a-teat :)) 

{cate- 1: 

< pre-cond : 

(FD  it-uted-terially ) 

(FD  it-a  {FLIGHT-DATA  {teal t-free:  0)  (lire:  S))» 

(return:  {no-more-tealt:)  > 

(pott-cond:  (FD  ii-o  {FLIGHT-DATA  {teatt -free:  0)  (lire:  S»)  >) 

{cate-2: 

(pre-cond: 

(FD  it-uted-terially) 

(FD  ii-o  (FLIGHT-DATA  (teatt-free:  N)  (lire:  S))) 

(N  > 0)  > 

<relurn:  ( ok-iti-retervcd :)  > 

(pott-cond:  (FD  ii-o  (FLIGHT-DATA  (teatt-freo:  N - 1)  (lire:  S)))  >)> 

(event:  (FD  <=  (cancel-a-teat:)) 

(cate-I: 

(pre-cond: 

(FD  it-uted-terially) 

(FD  it-a  (FLIGHT-DATA  ( teatt-free : S)  (lire:  $)))  > 

(return:  (too-many-cancelt:)  > 

(pott-cond:  (FD  it-a  ( FLIGHT-DATA  (teatt-free:  S)  (lire:  S)))  >) 

(cato-2: 

(pre-cond: 

(FD  it-uted-terially ) 

(FD  it-a  ( FLIGHT-DATA  (teatt-free:  N)  (lire:  S))) 

(N  < S) > 

(return:  ( ok-itt-cancelled :)  > 

(pott-cond:  (FD  it-a  (FLIGHT-DATA  (teatt-free:  N + 1)  (lire:  S)))  >)> 

Figure  3 A Specification  for  the  Flight-data  Actor 

In  this  specification,  the  restriction  of  the  serial  use  is  expressed  in  the  following  notation. 


(FD  it-uted-terially) 

stated  as  a precondition  for  events.  In  contrast  to  the  specification  above,  there  are  no  such 
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preconditlons  in  the  specification  of  the  air  line  reservation  system  (the  flight  actor)  in 
Figure  I.  Thus  the  reservation  system  is  specified  to  work  properly  even  if  it  is  accessed 
concurrently.  Also  notice  that  the  specification  above  has  no  statements  about  scheduling 
such  as  the  first-come-first-served  scheduling  which  is  stated  as  </or-et>enic...>-clause  in  the 
specification  of  the  air  line  reservation  system. 

6.  One-at-a-time 

In  this  section,  we  consider  how  the  serial  use  of  a flight-data  actor  is  realized  in 
environments  where  communicating  parallel  processes  try  to  use  the  flight-data  actor.  Our 
approach  is  to  surround  a flight-data  actor  FD  with  some  mechanism  which  arbitrates 
parallel  requests  to  the  flight-data  actor  FD  and  passes  these  requests  to  FD  in  the  serial 
fashion.  We  call  this  protection  mechanism  a one-at-a-time  guardian.  A one-at-a-lime 
guardian  can  be  easily  implemented  by  a seriaitzer[Atkinson&Hewitt77]  which  is  a 
general  synchronization  mechanism  in  the  actor  model  of  computation. 

Now  we  give  a specification  for  one-at-a-time  guardians.  A one-at-a-time 
guardian  is  created  in  an  event  where  an  actor  one-at-a-time  receives  a resource  (a 
flight-data  actor  in  this  case).  The  one-at-a-time  guardian  thereby  created  will  then  contain 
the  received  resource.  The  following  <ct>eni;.->-c1ause  expresses  this. 

<evcnt:  (one-at-a-time  <=  RESOURCE) 

Krciurn:  G*  > 

<pott-cond:  (G  ii-a  ( ONE-AT-A-TIME  RESOURCE))  » 

where  ( ONE-AT-A-TIME  < resource))  is  the  conceptual  representation  for  a one-at-a-time 
guardian  which  contains  <resource>.  Next,  we  specify  how  a one-at-a-time  guardian  G 
behaves.  In  general  a request  to  the  guardian  G,  which  is  an  arrival  of  a message  M at  G, 
eventually  causes  an  invocation  (or  use)  of  RESOURCE.  The  invocation  of  RESOURCE  begins 
with  an  access  to  RESOURCE  which  is  an  arrival  of  the  same  message  M at  RESOURCE  and 
ends  with  a reply  for  the  access  which  is  a return  of  some  result  of  the  invocation.  (See 
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the  Figure  4 below.) 


Figure  4 

Our  aim  of  using  a one-al-«-»ime  guardian  G is  to  control  invocations  of  RESOURCE 
by  parallel  requests  so  that  only  one  invocation  of  RESOURCE  takes  place  at  a time.  In 
order  to  do  so,  if  we  have  two  concurrent  requests,  the  end  of  the  invocation  by  one  request 
should  always  precede  the  beginning  of  the  invocation  of  the  other  request.  This  intuitive 
description  of  the  desired  behavior  of  a one-at-a-time  guardian  can  be  described  in  terms 
of  the  order  of  the  events  request,  access  and  reply  introduced  above.  Suppose  we 
have  two  requests,  REQUESTj  which  is  an  arrival  of  a message  Mj  at  G,  and  REQUEST-  which 
li  an  arrival  of  a message  Mj  at  G.  Then  REQUEST,  causes  ACCESS,  whjch  ls  an  arr(val  of 
**  resulting  in  rep/y-/or[ACCESSkJ,  in  this  order  (where  k stands  for  either  i 

or  j).  To  ensure  the  one-at-a-time  property  of  invocations  of  a resource,  the  following 
ordering  relation  must  be  satisfied: 

"if  REQUESTj  precedes  REQUEST^ 
then  reply-for[ ACCESS)]  must  precede  ACCESS^". 

Since  REQUEST^  always  precedes  ACCESSh  and  ACCESSk  always  precedes 
reply- for[ACCE$$^],  the  desired  ordering  relation  can  be  expressed  by  the  following 
diagram. 


y i 

ACCESS:  * 


'l'  ^ 

r«p/y-/or[ACCESSj]  > ACCESS j 

repl  y /or[ACCES  S jl 

This  behavior  of  the  one-at-a-time  guardian  is  formally  described  as  a 
specification  in  Figure  5 below.  Note  that  RESOURCE  must  be  guaranteed  to  reply. 

<e*>ent:  (one-at-a-tima  <=  RESOURCE) 

(return:  G*  > 

<pott-cond:  (G  is-a  {ONE-AT-A-TIME  RESOURCE))  » 

<for-eventt:  REQUEST;,  REQUEST: 

where  REQUEST,  = (G  <=  M-),  REQUEST:  = (G  <=  Mj) 

<pre-cond:  1 

(G  it-a  ( ONE-AT-A-TIME  RESOURCE)) 

(RESOURCE  it- guarantecd-to-reply) 

(REQUEST;  precedes  REQUEST^)  > 

(caused-eventt:  ACCESS;,  ACCESS;,  r«ply-/or[ACCESS;],  rop/y/orlACCESS:] 
where  ACCESS;  = (RESOURCE  <=  M,),  ACCESS.  = (RESOURCE  <=  M:)>  ‘ 

(post-cond: 

(REQUEST;  precedes  ACCESS;) 

(REQUESTj  precedes  ACCESSj) 

(ACCESS;  precedes  rep/y-/or[ACCE$$;]) 

(ACCESSj  precedes  rep/y-/br[ACCESSj]) 

(reply- /or[ ACCESS;]  precedes  ACCESSj)» 

Figure  5 A Specification  for  the  One-at-a-Time  Actor 

7 . Symbolic  Evaluation  of  tKe  Air  Line  Reservation  System 

Our  implementation  of  the  air  line  reservation  system  is  expressed  by  the  following 
simple  code: 


(create-fiight  at)  = (one-at-a-time  (create-flight-data  a)) 
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(Equivalently,  (craata-flight  =c)  s (ona-at-a-tima  <=  (craata-flight-data  <=  s)).  ) 

In  this  section  we  demonstrate  that  the  above  code  meets  the  specification  of  the 
air  line  reservation  system  given  in  Figure  I.  Our  method  for  the  demonstration  is  symbolic 
evaluation. 

The  symbolic  evaluation  of  the  code 

(ona-at-a-tima  (craata-flight-data  s)) 


reveals  the  following  facts: 

1)  an  actor  FO  is  created  by  (craata-flight-data  <=  s), 

2)  G is  created  by  (ona-at-a-tima  <=  FD)  and  returned,  and 

3)  the  two  actors  satisfy  the  following  assertions  immediately  after  the  creation  of  G 

(FD  »a-o  {FLIGHT-DATA  ( teati-free : a)  (sixo:  c)J) 

(G  u-n  ( ONE-AT-A-TIME  FD)). 


This  means  that  the  flight  actor  is  created  as  a ona-at-a-tima  guardian  G which  contains  a 
flight-data  actor  FD  with  a free  seats.  In  what  follows,  we  will  establish  that  the 
ona-at-a-tima  guardian  G satisfies  the  specification  for  the  flight  actor  in  Figure  I. 

The  <«veni:..>clause  in  the  specification  for  the  flight  actor  in  Figure  I specifies 
the  behavior  of  G in  terms  of  the  conceptual  representation 


(G  is-a  {FLIGHT  {woti-fr<‘«:...){*ize:...))) 

(Notice  that  F in  the  specification  for  the  flight  actor  is  instantiated  as  G.)  On  the  other 
hand,  G is  implemented  as  a ona-at-a-tima  guardian  which  contains  the  flight-data  actor  FD. 


t 


m 
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This  means  that  we  have  two  views  of  G and  correspondingly  two  different  conceptual 
representations  are  used  to  describe  the  state  of  G.  In  order  to  show  that  the 
implementation  satisfies  the  specification,  we  need  to  establish  some  relation  between  the 
state  of  G expressed  by 

(FLICIIT  (loan-free:...)  («izo:...)) 
and  the  state  of  FO  expresssed  by 

(FLIGHT-DATA  (sean-frce:...)(tixe:...)). 

The  relation  we  need  is: 

Tf  G satisfies  the  assertion 

(G  ii-a  ( FLIGHT  (iean-free:  n)  (size;  s))) 
in  a situation  where  G receives  a message  M,  then  FD  always  satisfies  the 
assertion 

(FD  is-a  ( FLIGHT-DATA  (teati-free:  n)  (size:  «))) 
in  the  situation  where  FD  receives  the  same  message  M (through  the 
on«-at-a»tim«  guardian),  and  vice  versa." 

This  relation  is  expressed  formally  as  follows: 

<implomentation-commentory: 

(G  is-o  (FLIGHT  (scan- free:  n)  (size:  *)))  in  S 
inhere  S = 5it[(G  <=  M)] 
if-and-only-if 

(FD  is-a  ( FLICHT-DATA  (scan- free:  n)  (size:  #)))  in  S’ 
inhere  S’  = 5it[(FD  <=  M)]  >. 

Si t[E]  expresses  the  situation  where  an  event  E takes  place.  The  above  implementation 
commentary  formally  describes  the  basic  idea  of  the  implementation.  It  can  be  viewed  as 
the  counterpart  of  an  "invariant"  in  parallel  process  environments,  which  was  first 
introduced  by  [Hoare  1972]  to  show  correctness  of  implementation  of  data  structures  which 
are  supposed  to  be  used  serially. 

It  should  be  noted  that  the  first-come-first-served  based  scheduling  by  the 


4. 
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guardian  G guarantees  the  above  relation.  If  the  guardian  does  more  complicated 
scheduling,  the  relation  needed  for  the  demonstration  may  not  be  so  simple.  For  more 
general  scheduling  cases,  see  [Yonezawa771 

L Establishing  the  <«wni:  (G  <s  {retervo-a-teat:}).  j-rlamo 
There  are  two  cases  to  be  considered.  We  only  consider  the  (C«**-2...)-clause. 

Case-2:  (G  u-o  {FLIGHT  {teatt-free:  n)  («*«;  .))),  (n  > 0) 

The  guardian  G receives  a (re*erve-o-*coi.)  message  M.  To  know  the  result  of  this 
event,  the  specification  for  ow-.i-.-iim*  in  Figure  5 is  used.  Since  the  flight-data  actor 
D is  guaranteed  to  reply,  the  specification  for  one-.t-.-|jm*  guarantees  that  the 
ireterve-a-teat:)  message  M is  received  by  FO.  To  know  the  state  of  the  flight-data  actor 
FD  at  the  time  of  the  arrival  of  M.  the  above  implementation  commentary  is  used.  Since 
the  state  of  G at  the  time  of  the  arrival  of  M at  G is  described  as: 

(G  it-a  {FLIGHT  (waii-frn:  n)  (site.*  *))), 
the  state  of  FO  at  the  arrival  of  M at  FO  is  described  as 

(FD  it-a  {FLIGHT-DATA  {teatt-free:  n)  (tun:  *))). 

Then  the  (Cow-2.„)-dause  in  the  Cwni.O-dause  of  the  specification  for  flight-data  actors 
in  Figure  3 is  referred  to.  Since  the  precondition  that  FD  must  be  used  serially  is  satisfied 
(because  FD  is  contained  inside  the  one-at-a-time  G).  the  (Caw-^)-clause  of  the 
specification  for  flight-data  actors  tells  us  that 

(1)  ( ok-iu-reterved :)  is  returned,  and 

(2)  the  state  of  FD  is  now  expressed  as: 

(FD  it-a  ( FLIGHT-DATA  {teat-free:  n - 1)  {tize:  *))). 
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(I)  is  what  the  <reiurn:...>-clause  in  the  specification  for  the  flight  in  Figure  I requires.  Since 
the  state  of  FD  expressed  as 

(FD  it-a  ( FLICIIT-DATA  {teat-free:  n - 1)  (««:  •))) 

remains  unchanged  until  the  next  message  M’  arrives  at  FD,  by  using  the  implementation 
commentary  in  the  other  direction  this  time,  we  know  that  the  state  of  G remains  unchanged 
as 

(G  it-a  ( FLIGHT  {Matt- fret:  n - 1)  {rite:  «))) 

until  the  message  M’  arrives  at  G.  This  is  what  (ne»t-cond:m>  clause  in  the  specification 
for  the  flight  actor  in  Figure  I requires.  Thus  Case-2  is  shown.  Case-1  may  be  shown 
analogously.  It  should  be  noted  that  induction  on  the  order  of  arrival  of  messages  is  used. 

IL  Establishing  the  (event:  (G  <=  (cnncn/-p-«>qi.O)...>-clause 
The  demonstration  for  this  event  is  analogous  to  that  of  I. 

III.  Establishing  the  C/or-otionti.O-clause 

The  event  where  the  flight  actor  G receives  a message  means  that  the  orM-at-a-tinw 
guardian  receives  the  same  message.  Suppose  that  M and  M’  arrive  at  G in  this  order. 

The  specification  for  the  ona-at-a-time  guardian  specifies  that  M*  is  not  received  by  FD 
until  the  reply  from  FD  for  M is  completed.  Therefore  the  reply  to  M’  always  takes  place 
after  the  reply  to  M.  This  is  what  the  specification  requires. 

IV.  Establishing  the  Confinement  of  the  flight-data  actor  FD 

The  discussion  in  I,  II  and  III  above  assumes  that  no  one  can  access  the  flight-data 
actor  FD  except  through  the  guardian  G.  This  assumption  always  holds  because  the  ^ 

flight-data  actor  FD  created  by  (craata-flighi-data  <=  c)  is  never  released  outside  the 
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orw-at*a-tim«  actor. 

8.  Further  Work 

We  are  currently  working  to  establish  a coherent  methodology  for  demonstrating 
that  a distributed  message-passing  system  will  meet  its  specifications.  By  using  the 
technique  of  symbolic  evaluation,  we  would  like  to  analyze  the  relationships  and 
dependencies  between  modules  in  a distributed  system.  This  approach  will  be  instrumental 
in  assisting  us  with  the  evolutionary  development  of  distributed  systems. 

We  are  also  working  on  the  application  of  procedural  objects  (such  as  actors)  to  the 
area  of  business  automation.  In  order  to  replace  paper  forms  and  paper  documents,  we  use 
“active"  forms  and  "active"  documents  which  are  displayed  as  images  on  the  TV  terminal 
accompanied  by  procedures.  Active  forms  and  documents  are  sent  from  one  site  to  another 
whereby  clerks  are  requested  to  provide  necessary  information  with  the  guidance  of  the 
accompanying  procedures.  Such  procedures  may  also  check  the  consistency  of  filled  items 
and  point  out  errors  and  inconsistencies  to  persons  who  are  processing  forms.  Thus  active 
forms  and  documents  accompanied  by  procedures  enormously  increase  the  flexibility  and 
security  of  message  and  document  systems.  Furthermore  we  propose  to  use  the  "language" 
of  forms  and  documents  as  the  basis  for  the  user  to  communicate  with  the  information 
processing  system.  One  of  the  ultimate  objectives  in  our  research  is  to  develop  a 
methodology  for  the  construction  of  real-time  distributed  systems  which  can  be  efficiently 
and  effectively  used  by  non-programmers. 
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